「GuardDutyを可視化して、君もGuardDutyマスターになろう！」というタイトルでClassmethod Odysseyに登壇しました #cm_odyssey
2024.07.09こんにちは、臼田です。
みなさん、GuardDutyと戯れてますか？(挨拶
今回は弊社20周年の特別なイベントであるClassmethod Odysseyで登壇した内容の共有です。
資料
登壇概要
GuardDutyを可視化して、君もGuardDutyマスターになろう！
Amazon GuardDutyの運用大変ですか？今回は日頃からGuardDutyを嗜んでいる立場から、みなさんに普段知る必要がないくらい深いGuardDutyの情報を提供します。念の為最新のGuardDutyのアップデートも織り交ぜつつ、みなさんがGuardDutyマスターになるために、GuardDutyの検出内容(Findings)を解釈し、可視化するための術をディープダイブして解説します。
解説
今回も来てしまいました、GuardDutyマニアのための内容です。
昨年も似たようなコンセプトで話しましたのでこちらもご確認ください。ある意味これの続編です。
というわけで、今回の内容「も」すごくコアです。本当に大丈夫ですか？
このセッションの楽しみ方としては、GuardDutyマニアの方は問題なく楽しめると思います。そうじゃない人でも、「とりあえずなんだかよくわからないけどニッチなことを話しているのを聞くのが好き」というスタンスであれば楽しめると思います。
いちおうおまけとして、最近のアップデートについてもまとめています。他にもおまけはあります！
本件とは別ですが、一般的なAWSセキュリティについては下記記事で確認してください。
そして、最近私はmini Security-JAWSという定常的にAWSセキュリティを勉強する勉強会を開催しています。主に初心者が中級者になることを目的とした勉強会です。詳しくはDoorkeeperをご確認ください。
この勉強会の中で、AWSセキュリティを日本語で学習するためのコンテンツをまとめているmini Security-JAWS Docsを作成していますので合わせてご活用ください。
登壇の背景
今回は弊社で提供しているセキュアアカウント インシデント自動調査機能の中で新しく調査結果の画像生成機能を実装しました。その時に行った研究の成果を発表する、GuardDutyの基礎研究結果発表です。
ちなみにこんな感じで可視化できます。よくないですか？
ついでに、最近このサービスで観測しているGuardDutyの状況についても共有します。
アジェンダは以下のとおりです。
- 最近のアップデート
- 最近のGuardDutyの観測状況
- GuardDutyの可視化
最近のアップデート
今回は直近半年くらいの下記8つのアップデートを紹介します。
- EBSマルウェアスキャンのAWS管理キー対応
- ランタイムモニタリング機能の共有VPC対応
- GetUsageStatistics APIにRDSの使用率追加
- EC2ランタイム保護のリリース
- 2TiBまでEBSマルウェアスキャン対応
- Malware Protection for Amazon S3リリース
- RDS ProtectionのRDS for PostgreSQL対応
- EC2ランタイム保護でUbuntuとDebian対応
[アップデート]Amazon GuardDutyのマルウェアスキャンがAWS管理キーで暗号化されたEBSのスキャンに対応しました
すべてのEBSに対してスキャンが可能になった
[アップデート]GuardDutyのランタイムモニタリング機能が共有VPCに対応しました
すべてのVPCでランタイムモニタリングが使えるようになった
[アップデート]Amazon GuardDutyの利用料金を確認するGetUsageStatistics APIにRDSの使用率が追加されました
RDSの詳細な使用率が出せるようになった
[アップデート]Amazon GuardDutyのEC2ランタイム保護がGAしたので詳細な動作確認してみた
re:Invent 2023でプレビューだった機能がGAした
[アップデート]Amazon GuardDutyのMalware Protectionが2TiBまでのEBSボリュームをスキャン出来るようになりました
1TiBから上限が上がった
ついにブロックができるようになった！Amazon GuardDuty Malware Protection for Amazon S3が発表されました！ #AWSreInforce
これまでのGuardDutyのオプションと違って、アプリケーション要件に合わせて組み込むS3のマルウェアスキャン。GuardDutyでブロックができるようになったのも大きい。
[アップデート]Amazon GuardDutyのRDS Protectionが遂にRDS for PostgreSQLにも対応しました
これまでAuroraのみ対応していたところに追加された
[アップデート]Amazon GuardDutyのEC2ランタイム保護でUbuntuとDebianのマルウェアスキャンに対応してました！
Amazon Linuxのみだったところに追加された
最近のGuardDutyの観測状況
弊社のインシデント自動調査においてここ1年くらいの観測した結果からくる、主要なFindingsの傾向とTipsを紹介します。
まず、主要な項目の月別の傾向遷移は以下のような感じです。
細かいのであまり詳細に見る必要はありませんが、各Findingsの解説などしていきます。
Recon:EC2/PortProbeUnprotectedPortはポートプローブされていて保護されていないポート22 / 3389などがあると検出されます。通常これが検出される環境はあまり適切ではなく、弊社実績でこれは減少傾向にありますがその要因は利用者傾向によります。
DefenseEvasion:EC2/UnusualDNSResolverは8.8.8.8などのパブリックDNSで過検知しやすいものです。ここ1年ぐらいこの検出が増えています。それらを利用していて過検知がある場合には、Finding Typesと該当IPを指定して抑制しておくといいでしょう。逆に言うとそれ以外のIPが検出される場合には超チェックのFindingsです。
Trojan:EC2/DGADomainRequest.BはDGAで作られたドメインに対するクエリを検出するものです。だいたいは明らかに不正な通信ですが、まれにWindows Serverの謎検出を複数環境で観測しています。
Behavior:EC2/NetworkPortUnusualはスポット作業をしたEC2などの正常系を過検知することが多いです。だいたいは正常な反応をしていると捉えればよいです。
アノマリ系もそこそこ検出されます。
Discovery:IAMUser/AnomalousBehaviorは最近比較的多く、特に様々なリソースをDescribeしていると検出されます。
Exfiltration:S3/AnomalousBehaviorはAthena/Glueなどを利用していると過検知されます。逆に言うと、攻撃者もそれらを利用してきますので注意が必要です。
Discovery:S3/AnomalousBehaviorはだいたい実際の利用者がS3周辺の操作を行った時に検出されます。
GuardDutyの可視化
いよいよ本題ですね。下記流れで説明します。
- GuardDuty可視化の概要
- 可視化する主要な項目
- 可視化のポイント
そもそもGuardDutyの可視化ってなんで必要なんだ、というところから話していきましょう。下記はAmazon Detectiveを利用した場合の可視化の機能です。
検出結果グループを分析する - Amazon Detectiveより
良くないですか？非常に良いんですが、しかしこの機能にも以下のような欠点があります。
- Finding Groupsでしか作れない
- 複数の検出の関連性を解決する用途
- 生成に時間がかかる
- 単体のFindingsでは作れない
そのため、GuardDutyの可視化はGuardDutyの検出時にすぐに状況を把握したい、簡易的でいいので直感的に関係性を理解できるようにしたいというモチベーションで私は実施しています。
具体的に可視化の手法としては、Vis.jsを利用してグラフを生成しています。
グラフを生成するための情報は、Finding Types毎に定義ファイルを作成し、一つ一つどのように可視化するか定義しています。
可視化する項目は送信元と送信先の2つです。外部と内部ですね。外部側はIPアドレスや国などが必要です。内部側はリソースの情報を可視化します。特にリソースのアイコンを使って直感的に理解できるようにします。そして、2つのエンティティの間の関係性についても知りたいです。
というわけで可視化すると以下のようになります。
利用するアイコンですが、可能な限りリソースアイコンを利用します。AWSのアイコンはサービスアイコンとリソースアイコンの種類があります。この図だと、EC2のアイコンではなくEC2インスタンスの、Route 53ではなくRoute 53 Resolverのリソースアイコンを利用しています。
2つのエンティティ間の矢印の向きは非常に重要です。この方向で意味が全く異なります。
リソースの説明は、リソースID以外にも人が識別するためのNameタグなどを抽出します。
ここまで見ると、簡易的過ぎると感じるかもしれませんが、もしこれで足りなければGuardDutyだけでは足りないということなので、Amazon Detectiveを利用していくといいでしょう。
先ほどDetectiveのデメリットは説明しましたが、メリットは下記のとおりです。
- ログの集計とクエリ
- ロケーションの可視化
- 関連性を解決しドリルダウンできる
最近下記Detectiveのアップデートもありましたので合わせて見ていただくとメリットが伝わると思います。
可視化のポイントも紹介します。
アイコンの配置を固定していきましょう。Vis.jsを利用すると、デフォルトで配置が動的になりますが、直感的に理解するために毎回固定の配置にします。今回は上が外部、下が内部になっています。具体的にはVis.jsではNodeのfixedオプションを利用して、固定して座標も指定します。このあたりをすべて設定ファイルで満たすように作り込みました。
上記はIAMタイプのFindingsですが、これらは特にAPI実行先のサービスが動的なため、アイコンも動的に変える必要があります。FindingsのAction -> ServiceNameからサービスの種別を判別すると良いでしょう。
そして、Findingsによっては矢印の方向も動的に変わります。ActionTypeがNETWORK_CONNECTIONの場合にConnectionDirectionでINBOUNDかOUTBOUNDか、通信の方向を確認して矢印を変更します。
結構細かいポイントがありますが、うまいことFindingsと付き合って可視化しましょう。
まとめ
GuardDutyの可視化はDetectiveの可視化にはないメリットがあり、運用時に直感的に自称を理解することができます。
ぜひやってみてください！
![[コスト大事] Amazon Athena で S3 の大量オブジェクトをクエリする場合はスキャン量だけでなくリクエスト量も意識しよう](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-764c44f07bcd41184fe62a432ae120ab/512a4cdcd05a0ed3ddea950fdf619fa0/amazon-athena)
![[アップデート]GuardDutyのGetFindingsStatistics APIが更新され、日付やアカウント単位での統計がサポートされました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-f1f1e80330aaa8917410e012de277155/263838c1009bccfef2d8a98f11615f2d/amazon-guardduty)
